% Formato della pagina:
\documentclass[a4paper,11ptn]{report}         % foglio A4, carattere 11pt e formato report

% Inclusione dei pacchetti:
\usepackage[italian]{babel}                   % Lingua italiana
\usepackage{graphicx}                         % Inserimento di immagini
\usepackage[colorlinks=true]{hyperref}        % Inserimento di link nel documento
\usepackage{url}                              % Inserimento di url diretti verso Internet (o e-mail)
\usepackage{eurosym}                          % compatibilita' con il simbolo dell'euro
\usepackage{fancyhdr}                         % permette la gestione dei campi ai bordi della pagina
\usepackage{lastpage}                         % permette di avere il numero dell'ultima pagina

% Configurazione dell'ambiente:
\hypersetup{linkbordercolor=1 1 1}            % eliminati i bordi dai link
\hypersetup{urlcolor=blue}                    % i link url sono scritti in blu
\hypersetup{linkcolor=black}                  % i link dell'indice sono scritti in nero

\graphicspath{{./immagini/}}                  % path dove si trovano le immagini

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% PAGINA 1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% INTESTAZIONE DEL DOCUMENTO
%\begin{document}
%\title{\textbf{\textbf{PIANO DI QUALIFICA}}}   % titolo del documento
%\maketitle
%\newpage

\begin{document}

\thispagestyle{empty}

\begin{center}

\includegraphics[scale=0.8]{logoSevenSoft.png}

\vspace*{1in}

\huge{\textbf{\textbf{PIANO DI QUALIFICA}}}

\end{center}

%\maketitle
%\includegraphics{logoSevenSoft.png}

\newpage


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% PAGINA 2
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% TABELLE : DESCRIZIONE DEL CAPITOLATO

%\pagenumbering{Roman}                          % modifica la numerazione delle pagine con i numeri romani

\fancypagestyle{empty}{
\fancyhead[L]{Piano di Qualifica}
\fancyhead[R]{\includegraphics[scale=0.3]{logoSevenSoft.png}}
\fancyfoot[C]{}
}

\thispagestyle{empty}                          % elimina il numero di pagina

\vspace*{0.5in}                                % spazia la tabella del capitolato dall'inizio della pagina

% TABELLA PER LA DESCRIZIONE DEL CAPITOLATO SCELTO
\begin{center}
\begin{tabular}{l}
\Large{\textbf{Capitolato: Simulatore File System}} \\        % nome del capitolato
\begin{tabular}{|p{6.5cm}|p{5cm}|}                            % misure delle colonne della tabella
\hline
\textbf{Data creazione:} & 29 Novembre 2009 \\                % data della creazione del documento
\hline
\textbf{Versione:} & 0.2 \\                                   % attuale versione
\hline
\textbf{Stato del documento:} & Formale, interno \\           % tipologia del documento
\hline
\textbf{Redazione:} & Alberto Longato, Luca Zanini \\                               % autore del documento
\hline
\textbf{Revisione:} &  Revisione dei Requisiti (RR) \\        % per che revisione e' il documento
\hline
\textbf{Approvazione:}  & Daniele De Matteo \\                      % chi approva il documento
\hline
\textbf{Committente:} & Dott. Claudio Palazzi \\              % il committente del progetto
\hline
\end{tabular} \\
\end{tabular}
\end{center}
\vspace*{2in}

% DIARIO DELLE MODIFICHE DEL DOCUMENTO
\begin{center}
\begin{tabular}{l}
\Large{\textbf{Diario delle modifiche}} \\                                 % intestazione della tabella
\begin{tabular}{|p{2cm}|p{3.3cm}|p{7cm}|}
\hline
\textbf{Versione} & \textbf{Data rilascio} & \textbf{Descrizione} \\
\hline
0.4 & 08 Dicembre 2009 & Addattamento a modello unico e completamento documento\\
\hline
0.3 & 06 Dicembre 2009 & Correzioni ortografiche varie\\
\hline
0.2 & 30 Novembre 2009 & Integrazione con punti successivi e correzioni\\                            % una delle modifiche
\hline
0.1 & 29 Novembre 2009 & Prima stesura documento \\    % una delle modifiche
\hline
\end{tabular}\\
\end{tabular}
\end{center}
\newpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% DA PAGINA 3 IN POI.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\pagenumbering{arabic}                                  % riporta la numerazione araba

\fancypagestyle{plain}{
\fancyhf{}
\fancyhead[L]{Piano di Qualifica}
\fancyfoot[C]{\thepage}
\fancyhead[R]{\includegraphics[scale=0.3]{logoSevenSoft.png}}
}

\pagestyle{plain}

\pagenumbering{Roman}                                   % imposta la numerazione romana maiuscola

\tableofcontents                                        % crea l'indice del documento

\newpage


\pagenumbering{arabic}

\fancypagestyle{plain}{
\fancyhf{}
\fancyhead[L]{Piano di Qualifica}
\fancyfoot[C]{\thepage\ di \pageref{LastPage}}
\fancyhead[R]{\includegraphics[scale=0.3]{logoSevenSoft.png}}
}

\pagestyle{plain}

% Capitolo 1 - INTRODUZIONE AL DOCUMENTO
\chapter{Introduzione}                           % titolo del capitolo
\section{Scopo del documento}                        % paragrafo del capitolo
Il presente documento si propone di fornire una linea generale su come verr\`{a} garantita la qualit\`{a} del prodotto.\\
La versione iniziale di questo documento ha valore contrattuale per la gara d'appalto; il documento verr\`{a} di seguito incrementato (ad es. includendo gli eventuali test) e le prossime versioni avranno valore contrattuale solo dopo l'approvazione del cliente.

\section{Funzionalit\`{a}}
Il prodotto soddisfer\`{a} tutti requisiti definiti e descritti nel documento denominato Analisi dei Requisiti.

\section{Affidabilit\`{a}}
Il prodotto garantir\`{a} una elevata affidabilit\`{a} grazie ai molteplici controlli cui sar\`{a} sottoposto.

\section{Efficienza}
Il prodotto avr\`{a} tempi di risposta e di esecuzione adeguati alle particolari esigenze di un software didattico. Le risorse utilizzate saranno sfruttate in maniera adeguata allo scopo di perseguire le finalit\`{a} funzionali, quali tempi di risposta ragionevoli, praticit\`{a} d'uso del prodotto e risultati didatticamente corretti.

\section{Usabilit\`{a}}
Il prodotto sar\`{a} utilizzabile dall'utente in maniera semplice, attraverso una interfaccia user-friendly ed intuitiva; inoltre sar\`{a} a sua disposizione una guida e svariati aiuti nei punti solitamente pi\`{u} complessi da comprendere nell'ambito del funzionamento di un \underline{FS}. Il prodotto sar\`{a} quindi in grado di chiarire eventuali dubbi, anche grazie all'utilizzo di una rappresentazione significativa del \underline{FS} e della sua evoluzione.

\section{Portabilit\`{a}}
SiFiSy sar\`{a} utilizzabile su qualunque \underline{SO} che supporti la tecnologia Java Virtual Machine; particolare attenzione sar\`{a} prestata al supporto sui \underline{SO} Linux, Mac OSX e Windows.

\section{Scopo del prodotto}
SiFiSy \`{e}  un simulatore di \underline{FS} che ha come obiettivo quello di mostrare agli studenti, ma in generale a qualunque utente interessato, il funzionamento e la logica di implementazione di diversi \underline{FS}, con la possibilit\`{a}  di confrontare le varie configurazioni scelte e condurre alcune analisi significative.

\section{Riferimenti}
Ove non chiaramente specificato si fa riferimento alle normative vigenti.

% Capitolo 1 - VISIONE GENERALE DELLA STRATEGIA DI VERIFICA
\chapter{Visione generale della strategia di verifica}
\section{Organizzazione, pianificazione strategica e temporale, responsabilit\`{a}}
Le responsabilit\`{a} verso il cliente sulle attivit\`{a} di verifica sono a carico del responsabile di progetto.\\
Durante la realizzazione del prodotto, il responsabile interno dell'attivit\`{a} di verifica \`{e} il verificatore. In particolare, viene nominato un responsabile tra tutti i verificatori attivi durante la fase, col compito di coordinare le verifiche e di redigere un documento riassuntivo dei test eseguiti. Tali documenti saranno necessari al responsabile di progetto per verificare la copertura dei test. Le attivit\`{a} di verifica cominciano indicativamente a met\`{a} di ogni fase o appena esiste un prodotto organizzato, su cui quindi abbia senso fare qualsiasi tipo di verifica.\\
Le attivit\`{a} di verifica sono pianificate come segue:
\begin{itemize}
\item Durante la fase di analisi dei requisiti, l'attivit\`{a} di verifica inizia nel momento in cui gli analisti presentano una prima stesura del documento, contenente i requisiti pi\`{u} immediati definiti con una prima analisi del capitolato. Il lavoro dei verificatori consiste nel controllare tale documento e nel comunicare agli analisti se vi sono mancanze, conflitti o ripetizioni dei requisiti trovati, e inoltre, se tali requisiti sono realizzabili. Il processo di analisi e quello di verifica procedono quindi con un certo grado di parallelismo. Una volta terminato il lavoro degli analisti, il documento finale sar\`{a} revisionato dai verificatori e, se approvato dal responsabile di progetto, sar\`{a}  consegnato al committente per permettergli di valutare l'offerta della SevenSoft riguardo al prodotto richiesto.
Il contenuto del documento sar\`{a} in parte negoziabile col committente, ovvero eventuali requisiti aggiuntivi, provenienti dal committente o dal fornitore, saranno oggetto di analisi per verificarne la fattibilit\`{a}. In questo modo, se l'offerta venisse accettata, il lavoro degli analisti, cos\`{i} come quello dei verificatori, potrebbe ripetersi per la definizione e la verifica dei nuovi requisti che eventualmente dovessero emergere dalla discussione col committente.
Le attivit\`{a} di verifica in questa prima fase saranno principalmente rivolte alla correttezza della forma e dei contenuti del documento di Analisi dei Requisiti.
\item Durante la fase di progettazione, saranno eseguite principalmente due fasi di verifica:
	\subitem Al termine della progettazione architetturale \`{e} compito dei verificatori stabilire se la progettazione fatta soddisfa i requisiti attesi dal cliente (prova di copertura).
	\subitem L'accettazione della progettazione architetturale d\`{a} il via ai progettisti per cominciare il processo di progettazione di dettaglio, che naturalmente dovr\`{a} essere fedele alla progettazione architetturale approvata. In questa seconda fase il lavoro di verificatori e progettisti pu\`{o}, ancora una volta, procedere con un certo grado di parallelismo. Cos\`{i} facendo sar\`{a} pi\`{u} facile garantire la correttezza di ogni singola parte progettata e alla fine baster\`{a} controllare che l'aggregazione di tutte le parti, precedentemente controllate e approvate, non sia fonte di errore.
\item Alla fine della fase di realizzazione saranno eseguiti test dinamici.
	\subitem Questi test di verifica avranno il compito di dimostrare l'affidabilit\`{a} e il funzionamento corretto del prodotto. I test saranno eseguiti inizialmente sulle singole unit\`{a} del prodotto, poi sull'aggregazione di pi\`{u} unit\`{a} fra loro e infine sul prodotto nel suo insieme.
\end{itemize}

\section{Risorse necessarie, risorse disponibili}
Nella verifica attuata durante la prima fase, la principale risorsa necessaria \`{e} il lavoro dei verificatori. Altre risorse rese disponibili ai verificatori sono i documenti (capitolato d'appalto per software SiFiSy) e il materiale didattico offerto dal corso di Sistemi Operativi del Prof. Palazzi.\\
Altre risorse (quali software per la verifica durante la progettazione, programmazione e qualifica) saranno rese disponibili ai verificatori nelle fasi successive.

\section{Strumenti, tecniche, metodi}
L'attivit\`{a} di verifica verr\`{a} divisa in due fasi:
\subsection{Analisi Statica}
Questa fase verr\`{a} effettuata sul codice e comprende le seguenti sottofasi di verifica:
\begin{itemize}
\item Analisi del flusso di controllo per accertare la corretta esecuzione del codice.
\item Analisi del flusso dei dati per accertare la corretta inizializzazione dei campi dati e delle variabili nelle istanze dei vari oggetti che compongono il software.
\item Inspection: per rilevare la presenza di difetti ed effettuare la lettura mirata del codice.
\end{itemize}

\subsection{Analisi Dinamica}
Questa fase prevede la prova di utilizzo del prodotto per quanto riguarda tutte le sue funzionalit\`{a} e verranno utilizzati i seguenti strumenti di validazione:
\begin{itemize}
\item Black box: verificher\`{a} la corretta comunicazione delle componenti controllando la validit\`{a} degli output prodotti.
\item White box: verificher\`{a} la logica interna del codice e la piena trasparenza del nostro prodotto nei confronti della struttura del progetto globale.
\end{itemize}

% Capitolo 3 - GESTIONE AMMINISTRATIVA DELLA REVISIONE
\chapter{Gestione amministrativa della revisione}
\section{Comunicazione e risoluzione di anomalie}
Eventuali anomalie riscontrate prima della consegna del prodotto al committente sono sotto la responsabilit\`{a} del gruppo SevenSoft, il quale si impegna a risolverle. SevenSoft prevede che le comunicazioni di anomalie possano pervenire solamente dal gruppo stesso.
Per la registrazione di anomalie si user\`{a} uno strumento esterno che permetter\`{a} di registrare la data di apertura e quella di eventuale chiusura di tale anomalia, aumentando cos\`{i} l'efficienza durante lo sviluppo.\\
Le comunicazioni di anomalie devono contenere le seguenti informazioni:
\begin{itemize}
\item Nominativo del verificatore o di chi ha riscontrato l'anomalia.
\item Data di creazione.
\item Natura dell'anomalia.
\item Piccola descrizione dello scenario e delle condizioni sotto le quali si \`{e} verificata l'anomalia.
\end{itemize}
Alla ricezione di una comunicazione di anomalia il responsabile:
\begin{itemize}
\item Valuta la criticit\`{a} dell'anomalia indicando (se possibile) il requisito al quale essa \`{e} associata (cap. 4 del documento di Analisi dei Requisiti).
\item Incarica un verificatore (in accordo con quanto definito nel Piano di Progetto) per svolgere test sull'anomalia:
	\subitem Se dagli accertamenti del verificatore risulta che l'anomalia \`{e} banale (ad es. una correzione ortografica in un documento) pu\`{o} essere risolta direttamente dal verificatore.
	\subitem Se dagli accertamenti del verificatore risulta che l'errore non esiste, allora il responsabile avverte chi ha sollevato la comunicazione che la gestione dell'anomalia \`{e} terminata.
	\subitem Se dagli accertamenti del verificatore risulta che l'errore esiste, la gestione dell'anomalia continua passando ad una seconda fase.
	%\subitem Se dagli accertamenti del verificatore risulta che l'errore esiste e il responsabile valuta alta la criticit\`{a} dell'anomalia, allora la gestione dell'anomalia continua passando ad una seconda fase.
\end{itemize}
La seconda fase per la gestione dell'anomalia continua coinvolgendo il personale addetto alla realizzazione del prodotto intermedio soggetto all'anomalia, allo scopo di valutare la soluzione. Se la soluzione migliore del problema non risulta vantaggiosa in termine di tempo e costi per committente, o le soluzioni possibili sono tutte in contrasto col modello di vita del prodotto (sequenziale), viene terminata la gestione dell'anomalia tenendo traccia dell'anomalia irrisolta in un documento che sar\`{a} corredo del prodotto consegnato. In caso contrario viene eseguita la correzione.\\
SevenSoft si impegna comunque a consegnare al committente un prodotto, per quanto possibile, privo di anomalie.

\section{Trattamento delle discrepanze}
Qualora le attivit\`{a} di verifica e validazione provassero l'esistenza di discrepanze in un prodotto semifinale, queste dovranno essere trattate con una procedura simile a quella della gestione delle anomalie (vedi quanto detto sopra). In sostanza una discrepanza \`{e} un discostamento dalle attese che ha il cliente o lo stesso gruppo SevenSoft per un prodotto semifinale. Deve essere fatto il possibile per portare la dissonanza ad assonanza. Qualora la procedura di trattamento delle discrepanze (dallo studio alla attuazione della soluzione) risultasse inaccettabile in termini di tempo e costi per il cliente o si presentasse come una situazione di elevato rischio di fallimento del progetto, la discrepanza non verr\`{a} risolta o verr\`{a} risolta solo in parte (secondo accordi che vengono presi col cliente in questa situazione).\\
Di ogni discrepanza devono essere documentate alcune caratteristiche:
\begin{itemize}
\item Responsabile/i della discrepanza (se individuabile).
\item Requisito non soddisfatto.
\item Criticit\`{a} (se la discrepanza \`{e} totale o parziale).
\item Risorse necessarie per la soluzione (costi, strumenti, ecc.).
\end{itemize}

\section{Procedure di controllo di qualit\`{a} di processo}
La qualit\`{a} del prodotto \`{e} garantita con la qualit\`{a} di processo. Molta attenzione di SevenSoft, in questo progetto, \`{e} focalizzata sull'incremento della qualit\`{a} dei processi durante la realizzazione del prodotto. Questo intento \`{e} realizzabile gestendo i processi con la tecnica PDCA che li rende misurabili, riproducibili e di pi\`{u} facile verifica. Durante i colloqui interni si parler\`{a} di qualit\`{a} del processo, e si tenter\`{a} di quantificarla per poi migliorarla.\\
La misurazione della qualit\`{a} di processo avviene:
\begin{itemize}
\item Definendo il processo, specificandone i proprietari, i requisiti e la criticit\`{a} (gravit\`{a} delle conseguenze se il processo contiene errori).
\item Esaminando l'output del prodotto, verificando quindi che il prodotto del processo abbia le qualit\`{a} e caratteristiche attese.
\end{itemize}
Per fare ci\`{o} \`{e} necessario innanzitutto definire quali sono le caratteristiche di qualit\`{a} del processo, per poi eseguire un'attivit\`{a} di verifica documentata per vedere se tali caratteristiche sono soddisfatte.\\
Da questi parametri \`{e} possibile avere una misura per decidere se le risorse messe a disposizione del processo erano maggiori o minori di quelle necessarie e, nel caso che il prodotto del processo non avesse le caratteristiche di qualit\`{a} aspettate, si avranno dei parametri per valutare quanto costa il miglioramento del prodotto del processo (in termini di tempo, risorse, costo).\\
L'amministratore si impegna a redigere delle norme per far s\`{i} che il prodotto del processo sia facilmente analizzabile e verificabile (strutturato, predicibile, modulare, chiaro e non ambiguo nei contenuti).

% Capitolo 4 - RESOCONTO DELLE ATTIVITA DI VERIFICA
\chapter{Resoconto delle attivit\`{a} di verifica}
\section{Documentazione}
L'incaricato alla verifica di ogni documento dovr\`{a} accertarsi che gli argomenti trattati siano conformi a quanto presente nella sezione Scopo del documento e che il contenuto di ogni sezione rispetti il titolo assegnato alla stessa.\\
Inoltre dovr\`{a} segnalare parti del documento che risultino poco chiare o ambigue, eliminare porzioni di testo ritenute superflue e privare il documento di ogni errore ortografico, grammaticale o dattilografico.

\section{Glossario}
Il glossario \`{e} sottoposto a una semplice lettura critica del testo.
%Il glossario viene fornito in un documento separato denominato (definire il nome) che raccoglie le definizioni, acronimi ed abbreviazioni di tutta la documentazione.\\

\section{Specifica dei test in base alle componenti}

\section{Analisi dei requisiti}
\subsection{Tecniche di verifica:}
\begin{itemize}
\item Inspection: lettura dei diagrammi \underline{UML} e dell'elenco dei requisiti, allo scopo di verificare la corretta corrispondenza fra il requisito e la fonte di provenienza.
\item Tracciamento dei requisiti: per ogni requisito verranno indicati il tipo di prova da effettuare per verificare se \`{e} stato soddisfatto e il componente da cui il requisito deriva.
\end{itemize}
%\subsection{Tracciamento dei requisiti}



\end{document}                      % FINE DEL DOCUMENTO
